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© System for controlling access privileges. 

© The system and method of this invention pro- 
vides an access control list which spans across 
object boundaries in an object oriented database. In 
addition to providing read and write access permis- 
sions, the access control list provides execute se- 
mantics which apply to the execution of methods in 
an object oriented database. Within the entries of the 
access control lists, each of the permissions for 
read, write, and execute can be assigned separately 
to each of a number of ids representing user ids or 
group ids. Upon request for access to the data by 
the user, the user id of the user and the group ids 
for which the user is a member are searched for 
within the entries to determine whether the user has 
C^the privileges to perform the operation requested 
^against the objects. In addition, the access control 
impolicies are inherited from an object's superobject; 
XT resulting in a least privilege for the object. 
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SYSTEM FOR CONTROLLING ACCESS PRIVILEGES 



This invention relates to a system for control- 
ling access privileges to data within a data pro- 
cessing system. 

in a relational database, data is viewed as rows 
and columns, where a row represents a record, in 
tables. In order to retrieve records that represent 
the spanning of multiple tables, relational operators, 
such as a join operation, are utilised. Although 
relational operators are used within applications or 
by users through a query language, these relational 
ooerations are not incorporated within the data 
such that the relational database manager can 
automatically intuit such relationships. In order to 
retrieve a record from the database, the user must 
have read permission for that record. In order to 
change the data in the record, the user must re- 
trieve (select and fetch) the data into memory, 
update the record in memory, and then write the 
updated record to the database. The user must 
have permission to write the record before the 
database manager allows the previous data to be 
overwritten in the database. Moreover, in order to 
update the record in memory, the user must be 
cognizant of the column's attributes, such as 
whether that column contains integers, characters, 
strings etc. 

In an object oriented database, the navigation 
through the data is similar to that of the network 
model where an object oriented database manager 
traverses the relationships defined amongst the ob- 
jects and subobjects. In contrast to the relational 
database model, relationships between objects and 
subobjects are defined through the data, and not 
through explicit operations. Moreover, in complex 
application environments, objects and their relation- 
ships usually show very complex internal structures 
and comprise larger numbers of properties: such 
properties include methods. In addition, the object 
oriented database model parallels the object ori- 
ented programming model in that one may inherit 
attributes and methods from predecessor objects. 
However, the object oriented programming model 
generally deals with objects that are temporal in 
nature, i.e.. memory resident. The object oriented 
database model extends the programming model 
by allowing one to deal with objects that persist, 
i.e.. are disk resident. One of the features of object 
oriented databases (analogous to the programming 
model) is to provide the ability to define generic 
ooerations. i.e. methods, which apply to the ob- 
:scts. for the purposes of mamouiating and retriev- 
ing them. In the relational database model, all oper- 
anons to retrieve and manipulate records are per- 
: crmed by using ine database manager's apptica- 
•.son programming interface or query language. The 



object oriented methodology insulates the users of 
the database from the data representation and/or 
data structures that comprise objects. All retrieval 
and update operations may be performed through 
5 the use of these methods. 

In the relational database model, access privi- 
leges may be set on the records such that grant 
and revoke authorisation privileges can be deter- 
mined per user of the database. The records are 
jo tagged with either read or write privileges for spe- 
cific users. For example, the first record could be 
read by users A. 8, and C. and only written by user 
C. Likewise, the second record could be tagged 
such that only user A has the permission to read. 
ts and only user A has the permission to write. 

For example, if a database contained payroll 
information, members of the payroll department 
may be able to read all of the payroll information 
for all departments except the payroll record for 
20 their payroll department. Only the manager of the 
payroll department would have the permission to 
read the record containing the payroll department 
data. If a user attempted to retrieve the records 
which did not define read privilege for the user, 
25 that user would not be granted the ability to see 
that record of data. 

One shortcoming of relational databases is that 
access permission control is on a record basis. 

Therefore in accordance with the present m- 
30 vention there is provided a system for controlling 
access privileges to data, the system comprising: 
means for assigning at least one access control 
policy across a plurality of objects in an object 
oriented database; and means for controlling a plu- 
35 rality of operations to at least one of the plurality of 
objects based on the assignment and at least one 
credential of a user requesting access to the data 
represented by at least one of the plurality of 
objects. 

4 0 The definition of an access control list thereby 

applies to objects in an object oriented database. 

According to preferred features of the invention 
ones of the plurality of operations may be a read 
operation, a write operation or an execute opera- 

4$ tion. 

If one of the plurality of operations is an ex- 
ecute operation it is a further preferred feature of 
the invention that the execute operation applies to 
the execution of at least one method associated 
50 with the object. 

The invention thereby applies an access con- 
trol list to authorise the invocation of an operation 
on an object for changing the state of the object in 
addition to the permissions of read and write ac- 
cess. 
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According to a further preferred feature of the 
invention the system further comprises means for 
inheriting the assigned at least one access control 
policy of the at least one object. The system may 
further comprise means for inheriting the assigned 
at least one access control policy by a second 
object descending from the at least one object. 

The definition of an access control list thereby 
spans the objects and subobjects in an object 
oriented database. 

According to a further preferred feature of the 
invention the means for inheriting comprises means 
for determining the least amount of privilege asso- 
ciated with at least one composite object accessed 
by the user. The at least one composite object 
may comprise one of the plurality of the objects 
and at least one subobject. 

In this way there can be provide a mechanism 
whereby access control policies on objects may be 
inherited from their superclass objects; resulting in 
the least privilege. 

According to another preferred feature of the 
invention the at least one access control policy is 
associated with a plurality of users and a plurality 
of groups. 

According to another aspect of the invention 
there is provided a procedure for controlling access 
privileges to aata. the method comprising: .assign- 
ing at least one access control policy across a 
plurality of objects in an object oriented database; 
and controlling a plurality of operations to at least 
one of the plurality or objects based on the assign- 
ment and at least one credential of a user request- 
ing access to the data represented by at least one 
of the plurality of objects. 

Each entry in the access control lists can con- 
tain access control information for either users or 
groups of users specified by the corresponding 
user ids or group ids. The access control list has 
the information necessary to determine the privi- 
leges of read, write, or execute for a set of users or 
groups. Furthermore, upon receiving a list of user 
ids and group ids. the access control check rou- 
tines perform a logical AND operation across the 
set of credentials represented by the different ids 
and returns the least amount of privilege. 

An embodiment of the invention will be de- 
scribed in the ensuing description with reference to 
the following figures, wherein 

Fig. 1 is a block diagram of the system of 
this embodiment having an object data manager for 
controlling the access to objec:s in an object 
database according to an access control policy 
associated with the objects and the user's creden- 
tials. 

Fig. 2A is a hierarchy of objects in an object 
database showing superobjects. oojects. and sub- 
objects. 



Fig. 2B is an illustration of an access control 
list for each object in an object database. 

Fig. 2C is a hierarchy of interface menu 
objects in and object database showing* superob- 
s jects. objects, and subobjects. 

Fig. 3A is a flow diagram of the object data 
manager utilising the access control facilities to 
determine whether a particular operation against a 
set of object classes and objects are permitted. 
w Fig. 38 is a flow diagram of the methodology 

for granting or revoking the operations based on 
the access control policies. 

Fig. 3C is a continuation of the flow diagram 
of Fig. 3A. 

TS Fig. 4 illustrates the structure of the access 

control list. 

Fig. 5A shows the access control policy of 
this embodiment used in conjunction with a system 
management interface tool for controlling the ad- 
20 ministrative views of menu objects. 

Fig. SB shows a hierarchy of system man- 
agement interface menu option objects. 

The data processing system 1 has an operat- 
ing system running in memory 3 which has tables 
25 30 which contains the credentials 31 for each ac- 
tive user 32. The credentials identity 31 contains 
the user id 33, and the group ids 34 for which the 
user belongs and other security information 35. In 
user memory 4. the object data manager 40 ac- 
- 30 cesses the objects found in ;he file system. The file 
system 20 resides on disk 2 which has object 
classes 50. as shown in Fig. 2A and Fig. 2C. 

Referring to figure 2A. object class 54 is a 
super class of objects 55 and objects 56. and 
35 objects 55 is a superclass of objects 57. An exam- 
ple is described in copending European application 
number (IBM internal docket No AT9-89-031), 
inventors RA Fabbio et al for "An Open System 
Management Architecture for a Data Processing 
„o System". Likewise, objects 55 are a subclass of 
object class 54. and object classes 57 are subob- 
jects of object class 55. The object class of the 
system management interface tool comprises inter- 
face menu option objects, as shown in Fig. 2C. An 
45 example of such an interface tool is described in 
copending European application number (IBM 
internal docket No AT9-89-039), inventors RA Fao- 
bio et al for "User interface tool". 

Refernng back to Fig. 1. the object data man- 
so ager 40 is cognizant of absolute access control 
policy assignment and authorisation per object. 
The authorisation process reviews the user's cre- 
dentials 31 described to tne object data manager 
40 and uses this .nformaticn to determine the oper- 
55 auons which are permissible on each obiect. 

When the obiect daia manager is requesteo to 
perform operations on specific objects, i.e. retrieve 
or modify, the ooject data manager first determines 
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the current credential attributes 31 for the user 32 
requesting the operation by interfacing with the 
kernel 3. The object data manager then performs 
the operation which may require inheritance or 
subclass traversal through the objects. As the ob- 
•ect data manager performs such an operation, the 
access control policies lists are checked for each 
obiect satisfying the criteria of the operation. Ac- 
cess control policies are treated like other at- 
tributes within an object class in that they may be 
inherited from other superclasses, thus altering the 
access control policies as traversal of the objects is 
performed. 

Fig. 28 represents a user defined view of the 
devices object class 54 and one of its subclasses, 
customised devices 55. Devices object class 50 
contains attributes 71, methods 72 and triggers 73. 
For example, for an object class of customised 
devices devices 55. the attributes 71 would repre- 
sent the definition of the object such as device 
name 74 character string, device id 75 integer 
number, and device type 76 character string, etc. 
The methods 72 are the operations that apply to 
the object. For example, a method of configuring 
the device 77. the method of defining the device 
78. the method of unconfiguring 79. and the meth- 
od of undefining 80 the object, etc. Triggers 73 
represent the events that are automatically invoked 
when the objects are manipulated. 

In addition to the user .'defined attributes 71, the 
object data manager transparently maintains a sep- 
arate access control list 100 as part of each object 
w.thin each object class. The access control list is 
further shown in Fig. 4. The access control list 100 
maintains the owning user id 101 and the owning 
group id 102 for each object. This owning informa- 
tion 101. 102 dictates the access control policy for 
maintenance to the access control list itself. Only 
those owning users and owning groups can alter 
the access control list in an object. Before any 
access control entry is altered for any object, the 
obiect data manager first verities that the user can 
be identified through its credentials in either the 
owning user id 101 or the owning group id 102. 

The access control attributes on each object 
consists of eight 32 bit entries 1 11-118. of which 
seven of these entries 111-H7 represent the user 
or group ids making up the access control list 100. 
The eighth entry 118 is divided into eight 4-bit slots 
121-128. where the first seven slots 121-127 repre- 
sent the privileges associated with the correspond- 
ing access control entry 1U-U7. The eighth 4-bit 
slot 128 is used to keep the count of the number of 
entries used. In the first seven 4-bit slots 121-127. 
the first three bus reoresent read, write, and ex- 
ecute privileges while the last bit of the 4-bu slot 
indicates whether the corresponding access control 
entry applies to a user or a group id. 



Fig. 3A illustrates the high level flow of the 
object data manager utilising the access control 
facilities to determine whether a particular opera- 
tion against a set of object classes and objects are 
s permitted. The object data manager opens the ap- 
propriate object classes, step 301 . and determines 
if the open succeeded, step 302. The object data 
manager then iterates for each object class that 
was opened, step 303. when the list of object 
,o classes opened are processed, the results are ac- 
cumulated and returned to the user, step 304. If 
there are object classes to process, the object data 
manager acquires the user's credentials from the 
operating system (resultant is the least privilege 
,s associated for that user based on the set's creden- 
tials) step 305. The object data manager then 
performs the retrieval of the selected objects, step 
306 and checks to see if the object is available for 
further processing.' step 310. specifically whether 
20 the access privileges for the user do not conflict 
with the access controls assigned to the object 
being accessed. Specifically, the object data man- 
ager checks in the operating system for the cre- 
dentials for the user, and checks these credent.als 
25 with the list of access control privileges defined by 
the objects retrieved. If the access priv.leges are 
denied, the object data manager then checks to 
see if there are more objects that meet that selec- 
tion criteria, step 31 5. If so. the object data man- 
30 ager returns to step 305. if not. the object data 
manager returns to step 303. Given that the object 
holds the appropriate access controls for further 
processing, step 320. the object data manager per- 
forms the specific operations generally def.ned by 
35 the methods. The object data manager accumu- 
tates the new set of access control information for 
the user based on the bitwise ANOing of the ob- 
ject's access controls, step 325 and returns to step 
315 to determine whether there are more objects to 
,o retrieve. In step 325. the object data manager uses 
this technique to inhent the least access privilege 
that spans the objects of interest. 

Fig. 3B describes in more detail step 310 from 
Fig 3A which describes the methodology for grant- 
.5 ing or revoking the operations based on the access 
control policies. The access control facility first 
determines whether the requested mode supplied 
to it are valid, step 328. Given that the modes are 
valid the obiect data manager defines a bit mask 
so which is 'representative of the requested modes, 
step 331. in addition, the object data manager 
accesses the in memory version of the access 
control list assigned to a particular object, step 33b. 
Once the access control list has been acquired, the 
55 object data manager determines the number of 
entries utilised w.thm the list, step 337. If the count 
is not greater lhan zero, step 331. the ooject data 
manager grants access to the object by the user. 
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step 341. If the count is greater than zero, the 
object data manager compares the user's creden- 
tials to the access control entry representing either 
a user or a group, step 344. If there is a match, the 
object data manager saves the index of the match- 
ing access control entry, step 346. It then checks 
to see if there are additional access control entries, 
step 352, and if so. returns to step 344. If additional 
entries do not exist, the object data manager deter- 
mines if there were any matches between the 
user's credentials and the object's access control 
entry, step 355. If there are none, the access is 
denied to the object for that user, step 357. If a 
match exits, the object data manager acquires the 
privilege bit mask defined for that user on that 
object, step 359. Fig. 3C. The object data manager 
then checks to see if the requested bit mask is 
greater than the user's bit mask defined by the 
access control entry within that object, step 361. If 
the requested bit masks is greater, then access is 
granted to the object for that user, step 363. If the 
requested bits are less than or equal to. then a 
bitwise ANO operation is performed between the 
requested bit mask and the bit mask found in the 
objects entry for that user, step 365. If the resultant 
is greater than zero, step 367, then access is 
granted to the object for that user, step 369. If the 
resultant is less than or equal to zero, then access 
is denied to that object for that user, step 272. 

If a particular user is associated with multiple 
groups, and identifies oneself with multiple groups 
when performing operations on the objects, the 
object data manager wilt perform a bitwise AND 
operation of the particular sets of credentials that 
are currently associated with that user. This results 
in a assigning the least privilege associated with 
the intersection of the credentials sets. 

The above described access control policies 
can be applied to various applications. An example 
of such an application is described in copending 
European aoplication number (IBM internal 

docket No AT9-89-039). inventors RA Fabbio et al 
for "User Interface Tool". The access control lists 
of this embodiment can be applied to a system 
management interlace tool for the purposes of de- 
fining the authorisation policies for the various 
views that may be accessed by a collection of 
system administrators with various authorities. 
Without this embodiment, one approach would be 
to define the collection of menus, dialogs, and 
prompts to represent the permutations of the var- 
ious administrative views associated with the dif- 
ferent administrative privileges. However, this tech- 
nique typicaily results m very large databases con- 
taining a great deal of reaundant information. 

In contrast, with the present emoodiment. the 
various menus, dialogs, and prompts are only 
stored once :n :ne object database, and are as- 



signed the appropriate access controls on the var- 
ious objects (menus, dialogues, prompts) such that 
the various permutations of administrative views 
are dictated by the access control policies, 
s For example. Fig, 5B shows a hierarchy of 

interface menu option objects for performing sys- 
tem management tasks. 500. Along with security 
and users. 504, other subclasses of system man- 
agement interface objects include devices, TCP/IP. 
70 physical and logical storage, communications ap- 
plications and services, problem determination, etc. 
As shown in Fig. 5A. administrator A. 551. may 
have read, write, and execute privileges for the 
user interface objects 553 which present the con- 
, 5 figurable domain of TCP IP. devices, and users 
while administrator B. 552. may have read, write, 
and execute privileges for the user interface ob- 
jects which present the configurable domain of just 
users. 554. However, administrator A. 551. may 
20 only have the privilege to access to view the users 
542 and the groups 543. while administrator B. 
552 has access to view and manage the access 
control lists. 541. the users 542. the groups. 543, 
and passwords. 544. Therefore, administrator A 
25 would only have access to menus 542. 543. while 
administrator B would have access to menus 542. 
543, 544. 541 as the subobjects of the configurable 
. domains menu object class for users. 

There has been described a system in which 
30 grant and revoke permissions, referred to herein as 
access control lists apply to a collection of objects 
in an object oriented database. An object data 
manager supports composite objects which are 
multiple objects and the access control polices 
35 that apply to such objects are transparent to the 
user. The access control lists span across the 
objects. Furthermore, not only do the access con- 
trol lists provide read and write permissions, but 
they also provide execution permission for oper- 
.o ations which apply to the objects. The execute 
semantics apply to methods that are invoked to 
perform operations on the objects. A user with 
execute permission can perform operations on 

those objects. 

d5 For example, if the objects in the object ori- 

ented database contained information on the con- 
figuration of a data processing system, a user 
could be either granted or revoked the permission 
not only to read the configuration data, but also to 

so perform configuration operations on the data. If the 
configuration information contained informat.on on 
the physical devices in the system, the user would 
De granted or revoked the oerm.ssion to configure, 
define, start, stop, unconi.gure. and undehne those 

55 devices. . 

While trie invention nas been particularly 
cnown and described w.th reference to a preferred 
embodiment. *t will be understood by those smiled 
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,n (he art that various changes may be made 
«,thout cepartcng from the scope of the invention. 



to 



20 



Claims 

1. A system for controlling access privileges to 
data, the system comprising: 

means for assigning at least one access control 
policy across a plurality of objects in an obiect 
oriented database; and 
means for controlling a plurality of operat.ons to at 
least one of the plurality of objects based on the 
assignment and at least one credential of a user 
requesting access to the data represented by at is 
least one of the plurality of objects. 

2. A system as claimed in claim 1 wherein one 
of the plurality of operations is a read operation. 

3 A system as claimed in claim 1 or claim 2 
wherein one of the plurality of operations is a write 

operation. . 

4 A system as claimed in any preceding claim 
wherein one of the plurality of operations is an 
execute operation. 

5 A system as claimed in claim 4 wherein the 
execute operation applies to the execution of at 
least one method associated with the object. 

6 A system as claimed in any preceding claim 
further comprising means for inheriting the as- 
signed at least one access., control policy of the at 

least one object. 

7 A system as claimed in any preceding claim 
further comprising means for inheriting the as- 
signed at least one access control policy by a 
second object descending from the at least one 

object. ■ w . 

8 A system as claimed in claim 7 wherein the 
means for inheriting comprises means for deter- 
m.ning the least amount of privilege assoc.ated 
with at least one composite object accessed by the 

user. . 

9 A system as claimed in claim 8 wherein the 
at least one composite object comprises one of the 
plurality of the objects and at least one subobject. 

10 A system as claimed in any preceding 
claim wherein the at least one access control poli- 
cy is associated with a plurality of users and a 

plurality of groups. . . 

H. A procedure for controlling access privi- 
leges to data, the method comprising: 
ass.gning at least one access control policy across 
a plurality of objects in an object oriented 
database; and 

controlling a plurality of operations to at least one 
of the plurality of objects based on the ass.gnment 
and at least one credential of a user requesting 
access to the oata represented by at least one of 
me plurality of objects. 
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© System for controlling access privileges. 

© The system and method of this invention pro- 
vides an access control list which spans across 
object boundaries in an object oriented database. In 
addition to providing read and write access permis- 
sions, the access control list provides execute se- 
mantics which apply to the execution of methods in 
an object oriented database. Within the entries of the 
access control lists, each of the permissions for 
read, write, and execute can be assigned separately 
to each of a number of ids representing user ids or 
group ids. Upon request for access to the data by 
the user, the user id of the user and the group ids 
for which the user is a member are searched for 
within the entries to determine whether the user has 
the privileges to perform the operation requested 
against the objects. In addition, the access control 
policies are inherited from an object's superobject; 
resulting in a least privilege for the object. 
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